Floppyshop 2/Floppyshop - 2.zip/Floppyshop - 2.iso/diskmags/0022-3.564/dmg-0086/473.txt

Text File | 1997-04-16 | 12KB | 281 lines

=========================================================================

INFO-ATARI16 Digest         Tue, 24 Apr 90       Volume 90 : Issue  473

Today's Topics:
                      Hard Disk Case for Sale..
           Looking for a Graphics Standard beyond ANSI VDI
      Possible to Have BACKGROUND IMAGE on Desktop like in Macs?
                      QuickST on the STart Disk
----------------------------------------------------------------------

Date: 24 Apr 90 02:53:17 GMT
From:
 usc!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!uflorida!haven!aplcen!jhu
 nix![e-mail]  (Ajay Choudhri)
Subject: Hard Disk Case for Sale..
Message-ID: <[e-mail]>

I have a hard drive case for sale.. Its pretty big and can handle 1 half height
and 1 full height or 3 half heights.

anyway it comes with power supply and fan and stuff. This is strictly
external, is very rugged. The bays are vertical not horizontal...
I'll try and do an ascii representation of the front.

       -----------------
       I I b I   I  b  II
       I I a I   I  a  II
       I I y I   I  y  II
       I I   I   I     II
       I I 1 I   I  2  II
       I I   I   I     II
       I I   I   I     II
       I I   I   I     II
       I I   I   I     II
       -----------------

As you can see at my bad attemot, this is pretty big, it is possible to
fit two full heights side by side, but the first bay would only 'show'
part of the drive.

If you need an external drive case with power supply and fan, this is a good
choice.  Its made by Zenith.

My asking price??
70 dollars.......or trade for miscallaneous IBM,MAC or Atari ST hardware
or software


e-mail or call me...you actually have a better chance e-mail-ing me
I am never home, and my answering machine is not cooperating.
but try...
 -Ajay
[e-mail]
[e-mail]
[e-mail]
 !uunet!aplcen!jhunix!ins_bac
C&P Telephone [phone](ask for A.J.)

Go Yankees, Manchester United, UNLV, NJ Nets, NJ Devils, Dallas Cowboys and
Johns Hopkins Lacrosse Bluejays


------------------------------

Date: 22 Apr 90 22:50:20 GMT
From: rochester!rit!cci632!ccicpg!felix![e-mail]  (Art Dederick)
Subject: Looking for a Graphics Standard beyond ANSI VDI
Message-ID: <[e-mail]>

In article <[e-mail]> [e-mail] (Ted A. Campbell) writes:
>So -- is there a limited set of X or MGR graphics/mouse routines that
>could be implemented on PCs, allowing me also an easy way to port my
>application to other computers, especially workstations?  I'd like
>very much to hear from you on this.

Look at STDWIN.  I obtained it from osu-cis.  The following is
the beginning of the "ABOUT" file.

[Last modified on Sat Jul 30 18:04:08 PDT 1988 by gvr]

1. Target systems

STDWIN is aimed at C programs.  It consists of a few header files (of
which only one is visible to the user) and a library.  In most cases
some system-provided libraries must also be used in the linking phase.

Currently, full STDWIN is available for the following environments:

(Note that in all cases the code is in beta test state; there may be
bugs, functionality may change slightly in the future and new
functionality may be added, but the basic framework isn't going to
change much.)

*       X version 11 release 2
*       Apple Macintosh using either LightspeedC (2.15) or MPW C (2.02)
*       Atari ST using Mark Williams C (2.1)
*       Whitechapel MG-1 running an old version of 4.2 BSD

You may volunteer to create a version for your favourite system, or to
port it to your favourite C compiler for one of the mentioned micros.

A subset emulating most of STDWIN's functionality on an alphanumeric
display (this excludes line drawing but includes windows, menus, text
editing etc.) is available for:

*       Any decent Unix that has termcap (tested with 4.?2,3? BSD)
*       MS-DOS using the Microsoft C compiler (4.0)


2. Getting the full scoop

I have written a paper about STDWIN which has been published as a
CWI report (Guido van Rossum: STDWIN -- A Standard Window System
Interface.  Centre for Mathematics and Computer Science, report
CS-R8817.  Amsterdam, 1988).  You might get a copy mailed to you by
politely asking our secretary, Marja Hegt <[e-mail]>.

You can also get a source version for any or all of the above-mentioned
systems.  This is essentially a directory dump of my working version,
until I have the time or get some help to prepare a real distribution.
It is available through anonymous ftp access to gatekeeper.dec.com,
whose IP address is [128.45.9.52].  The directory is pub/stdwin; get
the file README for further instructions.  A version of the document
you're currently reading is in the file ABOUT.

Distribution outside the USA is solely by electronic mail.  Be prepared
to receive up to half a megabyte (in 50K pieces, tarred/ compressed/
uuencoded/ split).  If you're interested, write to:
  [e-mail]
(after October 14, 1988, try once again [e-mail].)

3. Basic functionality

STDWIN allows multiple "full-function" windows, roughly in Macintosh
style (title bar, grow box, close box, scroll bars).  The appearance of
windows is determined by the default of the underlying window manager,
and so are other limitations (e.g., overlapping, maximum size, etc.).
Windows are dynamically created and destroyed by the application, never
directly by the user or the window manager.

STDWIN uses a coordinate system derived from the display's coordinate
system: (0, 0) is top left, with X pointing right and Y pointing down
(these are actually called h and v).  Pixel size is that of the display.
There are enquiry functions to ask for the display size in pixels and in
millimeters.

The application is responsible for redrawing the window contents when it
is exposed.  This is done by associating a "draw procedure" with each
window, which knows how to draw the entire window's contents.  It gets
passed a pointer to the window and the coordinates of the rectangle that
needs to be redrawn, so it can (although it needn't) restrict itself to
that area.  STDWIN guarantees that a window's redraw procedure is only
called while the application is waiting for an input event (most
implementations simply turn exposure events into calls to the draw
procedure).

If the application wants to change part of the graphics it is
displaying, this is usually done in a two-phase process: first, STDWIN
is told that a particular area of the screen must be changed; later,
when the application starts waiting for input events again, the draw
procedure is called to update the indicated area (and any other area
that was exposed or damaged in some way).

The application defines the width and height of the area it wants to
draw; this needn't bear any relation to the window or screen size.  This
area is called the "document" although you may also think of it as a
virtual window.  The actual window generally displays a sub-area of the
document; the window's scroll bars indicate the position of the window
with respect to the document.  The application always uses the
coordinates of its document; STDWIN performs the translation to window
or screen coordinates are required by the window manager, and ensures
clipping of all output to the window.

STDWIN is event-based.  An application is expected to have a main loop
containing a "get event" call followed by a switch on the event type.
There is no event mask; an application can simply ignore events it isn't
interested in.  The most important event types are:

ACTIVATE:       A window becomes active (keyboard attached and/or topmost)

CHAR:           ASCII character key pressed (except BS, TAB, CR)

COMMAND:        special key or function (CLOSE, TAB, RETURN, BS, CANCEL,
                arrow keys etc.)

MOUSE:          MOUSE DOWN, MOUSE MOVE (only while down), MOUSE UP;
                fields in the event record indicate the h, v position,
                the number of the button, and the "click number" if the
                event is potentially part of a multiple-click sequence

MENU:           menu id and item number of a menu selection

SIZE:           user has resized the window

TIMER:          the window's timer went off; each window has one
                programmable timer which can be set to go off at N/10
                seconds in the future.  When the timer goes off a TIMER
                event is returned.

Currently, STDWIN draws text in a single font.  The actual font used
depends on the underlying window manager (and can sometimes be
influenced by the application programmer and/or the end user in a
system-dependent manner).  The font may be proportionally spaced, and
there are enquiry functions to find out the dimensions of characters and
strings.

There are functions to draw text and simple lines, rectangles and
circles, and ways to erase, shade or invert rectangular areas.  There is
no way (yet) to do general bitblt operations, or to influence the pen
shape.

------------------------------

Date: 24 Apr 90 10:12:01 GMT
From:
 snorkelwacker!usc!zaphod.mps.ohio-state.edu!uwm.edu!ux1.cso.uiuc.edu!cs325ec@tu
 t.cis.ohio-state.edu  (Gregory Lemperle-Kerr)
Subject: Possible to Have BACKGROUND IMAGE on Desktop like in Macs?
Message-ID: <[e-mail]>

[e-mail] (Imran Anwar) writes:

>Hi. I was wondering if it is possible to have a picture or image in the
>background instead of the dull desktop?

>I have seen such stuff on the Macs....so obviously it should be available on
>a better machine like the ST :-)

>Imran Anwar

Download degadesk.arc from terminator, it does what you ask... Also
switcher.lzh (by moi) will allow you to do what the mac does... randomly
select a picture on startup.  I used the auto folder program until Gemini
(which didn't always work with it) then the accessory until Calamus which
doesn't work on the menubar???  There are a couple of versions and the
source is included.

-- Greg

------------------------------

Date: 21 Apr 90 21:07:56 GMT
From: cs.umn.edu!thelake![e-mail]  (Steve Yelvington)
Subject: QuickST on the STart Disk
Message-ID: <[e-mail]>

[In article <9004201800.AA18499@xap>,
     [e-mail] (Bob Stewart) writes ... ]

> I'm typing this via Flash to my Unix system, with QuickST from the May STart
> disk running.  It leaves cursor blobs all over the place and often doesn't put
> the cursor where it belongs.  Yucky.  I'd feel bad about distributing software
> that doesn't work any better than that.

Imagine that you're in third grade and you have to walk to school.
You have three options: A long, winding route; a shorter route that
requires a couple of steep hills, and a shortcut through a few back yards.

The trouble with cutting through back yards is that somebody's dog is
liable to bite you.

One of the back yards QuickST cuts through fouls up VT52 cursor
positioning. I don't think the shortcut is worth getting bitten. It screws
up the programs that I use most. That doesn't mean it's bad software, but
it does make it useless here at the lake, and probably for a lot of other
people, too.

This is not a new problem, incidentally. I reported it a year or so ago.
The response I received indicated that it's a known "feature" -- a
tradeoff made when cutting corners.

--
   Steve Yelvington at the lake in Minnesota
   [e-mail]

------------------------------

End of INFO-ATARI16 Digest V90 Issue #473
*****************************************